Sourced from gradle-wrapper's releases.

9.7.1

The Gradle team is excited to announce Gradle 9.7.1.

This is a patch release for 9.7.0. We recommend using 9.7.1 instead of 9.7.0.

Here are the highlights of 9.7.0 release:

• Isolated Projects graduates to incubating
• Broader Configuration Cache compatibility
• Resilient Sync helps you fix broken builds
• More source locations in problem reports

Read the Release Notes

We would like to thank the following community members for their contributions to this release of Gradle: Adam, Aman Gautam, Aman Kumar, Anton Dubrouski, Aurimas, gbhavya07, Josh Friend, nicklauslittle-gov, Pragati, project516, Qin Mi, Ravi, sk-reddy17, Suvrat Acharya, Yongshun Ye.

Upgrade instructions

Switch your build to use Gradle 9.7.1 by updating your wrapper:

./gradlew :wrapper --gradle-version=9.7.1 && ./gradlew :wrapper

See the Gradle 9.x upgrade guide to learn about deprecations, breaking changes and other considerations when upgrading.

For Java, Groovy, Kotlin and Android compatibility, see the full compatibility notes.

Reporting problems

If you find a problem with this release, please file a bug on GitHub Issues adhering to our issue guidelines. If you're not sure you're encountering a bug, please use the forum.

We hope you will build happiness with Gradle, and we look forward to your feedback via Twitter or on GitHub.

• 92f0512 update fixed issues for 9.7.1 (#38892)
• 820ee75 update fixed issues for 9.7.1
• 82c23f9 Fix annotation parameter ordering problem in KTS (#38878)
• ef11a72 Fix annotation parameter ordering issue
• bb0d8a9 Make relevant tests polyglot (run for multiple DSLs)
• 336e129 Update signing configuration (#38874)
• 4bdf0da Update signing configuration
• cd9b92c List issues resolved in 9.7.1 (#38839)
• 5f4e381 List issues resolved in 9.7.1
• 1e08ab5 Keep type-use annotations in extracted ABI classes (#38810)
• Additional commits viewable in compare view

Sourced from ch.qos.logback:logback-classic's releases.

Logback 1.6.3

2026-08-14 Release of logback version 1.6.3

• In response CVE-2026-19880, MDCBasedDiscriminator (used by SiftingAppender) now strips forward and backward slashes (/, \) from MDC values before they are used as discriminating keys. This prevents path segments from escaping into destinations controlled by an attacker. When sanitisation actually changes a value, a warning is emitted; the warning is rate-limited (a small batch, then a lull of about ten minutes).

• Colour console support is split out into a dedicated JansiConsoleAppender. It wraps stdout or stderr with Jansi so ANSI escape sequences (for example coloured patterns) render correctly on terminals that need it, notably Windows. Prefer this class over the older path described next. See the appenders documentation.

• The withJansi property on ConsoleAppender is deprecated. Existing configurations that still set <withJansi>true</withJansi> continue to work for compatibility, but new setups should use JansiConsoleAppender instead.

• ConsoleAppender no longer treats the process console as an exclusive resource: stopping it does not close System.out / System.err. JansiConsoleAppender pairs each AnsiConsole.systemInstall() with systemUninstall() on stop, so repeated start/stop cycles do not leave Jansi installed or tear down streams shared with the rest of the JVM. Related behavior is covered by tests for issues/1063.

• Invocation throttling helpers were reworked: SimpleInvocationGate is renamed FixedIntervalInvocationGate, and BatchedFixedIntervalInvocationGate allows a short burst of invocations before applying a fixed lull. The sanitisation warning above uses the batched gate.

• The JPMS module-info for logback-core now exports the ch.qos.logback.core.property package, which had been missing from the module descriptor.

• A bit-wise identical binary of this version can be reproduced by building from source code at commit e8e824dede022a6d7208b36cfa875b0d1b7772f3 associated with the tag v_1.6.3. The release was built using Java "21" 2023-10-17 LTS build 21.0.1.+12-LTS-29 under Linux Debian 11.6.

-- Sponsoring SLF4J/logback/reload4j at https://github.com/sponsors/qos-ch

Logback 1.6.2

clean.full.1.6.2.mp4

2026-08-10 Release of logback version 1.6.2

• Configuration analysis now detects contradictory caller-data inclusion instructions. For example, an AsyncAppender, SocketAppender or SMTPAppender with includeCallerData left at the default false is incompatible with a layout or encoder pattern that uses a caller-data converter such as %C, %M, %L, %F, %l or %caller. At runtime those converters would print question marks and still incur extraction cost on a worker thread. Logback now emits a configuration-time warning when such instructions disagree. See codes.html#callerContradiction for details. This issue was reported in issues/1059 by leeychee. The initial analysis was contributed by seonwoo_jung.

• Caller-contradiction analysis can be turned off by setting the logback.skipCallerContradictionAnalysis variable to true, either as a system property (-Dlogback.skipCallerContradictionAnalysis=true) or as a property in the configuration file:

  <property name="logback.skipCallerContradictionAnalysis" value="true"/>

• SimpleSocketServer and SimpleSSLSocketServer now require an explicit client IP whitelist. On the command line, pass one or more allowed addresses (single IPs or CIDR ranges) after the configuration file. An empty whitelist means no clients are accepted. When embedding the server programmatically, register allowed addresses with addAllowedClientAddress(String) or setAllowedClientAddresses(Collection) before clients connect. See the documentation on restricting client access.

• Added ThrowableProxyVOBuilder for assembling a ThrowableProxyVO field by field, with a corresponding ThrowableProxyVO.builder() entry point.

• Dependency analysis handlers now run their postHandle method after child models have been processed, so checks that depend on nested appenders (such as caller-contradiction analysis) see a complete picture.

• Updated several dependencies, including Angus Mail to 2.0.4 and Jetty (test) to 12.1.12.

• A bit-wise identical binary of this version can be reproduced by building from source code at commit e3d78330ad1ba024fd987fd00c3ffb9cfcdb07dc associated with the tag v_1.6.2. The release was built using Java "21" 2023-10-17 LTS build 21.0.1.+12-LTS-29 under Linux Debian 11.6.

• e8e824d prepare release 1.6.3
• 761821b MDCBasedDiscriminator has a gated warning mechanism
• 53ed122 update copyright year
• c7e2db2 rename SimpleInvocationGate as FixedIntervalInvocationGate
• b5aa931 added BatchedSimpleInvocationGate
• 1f22af7 add javadocs to SimpleInvocationGate
• 638ffa7 prevent forward and backward slashes to escape to other directories
• 7d6b9a4 add missing ch.qos.logback.core.property package
• fa25930 add an extension path in ConsoleAppender for JansiConsoleAppender
• c73b43f deprecate the withJansi path
• Additional commits viewable in compare view

• See full diff in compare view

Sourced from com.github.skydoves:compose-stability-runtime's releases.

0.13.0

Upgrading

If you have committed .stability baselines in a multi-module project, run ./gradlew stabilityDump once after upgrading and commit the result.

This release fixes a false positive where a module's own types were reported UNSTABLE whenever a sibling Gradle module's group happened to be a package prefix (common with allprojects { group = "com.example" }). The corrected verdicts move UNSTABLE -> STABLE, and with the default failOnStabilityChange = true / ignoreNonRegressiveChanges = false, stabilityCheck reports improvements too, so it will fail until the baseline is refreshed.

Single-module projects are unaffected.

---

Changed

• Bumped Kotlin to 2.4.10 (from 2.4.0). Use the same Kotlin version as this library. The compiler plugin, runtime, Gradle plugin, Lint rules and IntelliJ plugin all build against 2.4.10, and every published target still compiles. No stability verdicts change: the Compose compiler's analysis/Stability.kt is byte-identical between 2.4.0 and 2.4.10, and re-running stabilityDump on the sample app produced no diff, so committed .stability baselines do not need refreshing for this bump alone.

  2.4.10's one Compose compiler fix, b/522127447 ("classes previously inferred stable now reported runtime/Uncertain"), is in ComposableFunctionBodyTransformer, not in stability inference. It restores the cast target type's stability when an argument is passed through a CAST/IMPLICIT_CAST, which affects the $changed metadata Compose computes per call-site argument. This analyzer reports the stability of a parameter's declared type, so the fix is orthogonal to what stabilityDump and the IDE surface.

• allowIncrementalDisabling is now scoped per project. Previously a stability task anywhere in the build disabled Kotlin incremental compilation in every project applying the plugin. Each project now decides based on its own task paths. ./gradlew stabilityDump, stabilityCheck and check behave identically; only a path-qualified invocation such as ./gradlew :app:stabilityCheck differs, and there it is more correct — that task only reads :app's own stability-info.json.

• The implicit :stability-runtime / :stability-lint project wiring is gone. The plugin used to call rootProject.findProject(...) and, when a module with either path existed, add that Project object as a dependency notation. That only ever resolved inside this repository, silently hijacked any consumer build containing a module with those names, and is deprecated in Gradle 9 (an error in Gradle 10). The published Maven coordinates are now always used; lint checks continue to ship inside the runtime AAR's lint.jar.

• The compiler plugin's projectDependencies option is deprecated and ignored. It stays registered so builds that pin the compiler artifact independently keep working, and will be removed in 1.0.

Fixed

• Gradle Isolated Projects compatibility (#107): the plugin no longer performs any cross-project access at configuration time, so builds using --isolated-projects / org.gradle.isolated-projects=true (incubating since Gradle 9.7) configure and compile cleanly. Two violations are gone:
  • collectProjectDependencies() walked rootProject.allprojects and read every sibling project's group, projectDir and path — including a filesystem scan of each sibling's sources — on every Kotlin compile-task configuration.
  • The incremental-compilation guard read gradle.taskGraph.allTasks, which observes tasks created by other projects.
• Types declared in the module being compiled are no longer mis-reported as UNSTABLE: cross-module detection used to match a parameter type's fully-qualified name against package prefixes guessed from sibling projects, and the first guess was the sibling's Gradle group. With the very common allprojects { group = "com.example" }, that prefix also matched the module's own com.example.* types, marking them unstable. Detection now relies solely on the IR declaration origin (IR_EXTERNAL_DECLARATION_STUB), which is the signal the Compose compiler itself uses and already covered every cross-module case. If you were affected, run ./gradlew stabilityDump to refresh your baseline — with the default failOnStabilityChange = true, stabilityCheck will otherwise fail on the resulting UNSTABLE → STABLE transitions.
• Cross-module types report an accurate reason: they were labelled UNSTABLE (has mutable properties or unstable members) even when they had none. They now read UNSTABLE (cross-module type without @Stable/@Immutable). Reasons are not compared by stabilityCheck, so this alone cannot fail a build.
• Stability verdicts no longer depend on compiler-plugin ordering: @StabilityInferred is honoured only on declarations from outside the module being compiled, where it is baked into the binary and is the intended cross-module channel. On a class in the module being compiled it exists only after the Compose compiler plugin's IR lowering has run, and whether that happens before or after this plugin is decided by the resolved order of kotlinCompilerPluginClasspath. The same source could therefore report STABLE in one build and RUNTIME in another. Our own property analysis is authoritative for source classes, and ignoring the annotation there also matches the IDE plugin, which only ever sees source.

Note for contributors

The sample :app module now resolves the runtime from its published coordinate like any consumer, instead of from the in-build :stability-runtime project. Two consequences: ./gradlew :stability-runtime:publishToMavenLocal must run before :app picks up local runtime edits, and after a version bump :app cannot build until the new version is published to Maven Local.

That change also shifted where the analyzer's IR pass sits relative to the Compose compiler plugin's IR lowering — plugin order follows the resolved kotlinCompilerPluginClasspath order, and the in-build project dependency used to push the analyzer behind Compose. Consumers were always on the other side of that boundary, so nothing changes for them, but app/stability/*.stability was regenerated and now records what a real consumer sees: composable-lambda parameters render in their pre-lowering form (@[Composable] ComposableFunction0<T> rather than Function2<Composer, Int, T>), and Icon.normalSealedClass reports RUNTIME instead of STABLE because @StabilityInferred is not yet attached to same-module classes when the pass runs. The analysis no longer depends on that ordering — see the @StabilityInferred entry under Fixed — so the regenerated baseline is now stable regardless of how the plugin classpath resolves.

Sourced from com.github.skydoves:compose-stability-runtime's changelog.

[0.13.0] - 2026-08-22

Changed

• Bumped Kotlin to 2.4.10 (from 2.4.0). Use the same Kotlin version as this library. The compiler plugin, runtime, Gradle plugin, Lint rules and IntelliJ plugin all build against 2.4.10, and every published target still compiles. No stability verdicts change: the Compose compiler's analysis/Stability.kt is byte-identical between 2.4.0 and 2.4.10, and re-running stabilityDump on the sample app produced no diff, so committed .stability baselines do not need refreshing for this bump alone.

  2.4.10's one Compose compiler fix, b/522127447 ("classes previously inferred stable now reported runtime/Uncertain"), is in ComposableFunctionBodyTransformer, not in stability inference. It restores the cast target type's stability when an argument is passed through a CAST/IMPLICIT_CAST, which affects the $changed metadata Compose computes per call-site argument. This analyzer reports the stability of a parameter's declared type, so the fix is orthogonal to what stabilityDump and the IDE surface.

• allowIncrementalDisabling is now scoped per project. Previously a stability task anywhere in the build disabled Kotlin incremental compilation in every project applying the plugin. Each project now decides based on its own task paths. ./gradlew stabilityDump, stabilityCheck and check behave identically; only a path-qualified invocation such as ./gradlew :app:stabilityCheck differs, and there it is more correct — that task only reads :app's own stability-info.json.

• The implicit :stability-runtime / :stability-lint project wiring is gone. The plugin used to call rootProject.findProject(...) and, when a module with either path existed, add that Project object as a dependency notation. That only ever resolved inside this repository, silently hijacked any consumer build containing a module with those names, and is deprecated in Gradle 9 (an error in Gradle 10). The published Maven coordinates are now always used; lint checks continue to ship inside the runtime AAR's lint.jar.

• The compiler plugin's projectDependencies option is deprecated and ignored. It stays registered so builds that pin the compiler artifact independently keep working, and will be removed in 1.0.

Fixed

• Gradle Isolated Projects compatibility (#107): the plugin no longer performs any cross-project access at configuration time, so builds using --isolated-projects / org.gradle.isolated-projects=true (incubating since Gradle 9.7) configure and compile cleanly. Two violations are gone:
  • collectProjectDependencies() walked rootProject.allprojects and read every sibling project's group, projectDir and path — including a filesystem scan of each sibling's sources — on every Kotlin compile-task configuration.
  • The incremental-compilation guard read gradle.taskGraph.allTasks, which observes tasks created by other projects.
• Types declared in the module being compiled are no longer mis-reported as UNSTABLE: cross-module detection used to match a parameter type's fully-qualified name against package prefixes guessed from sibling projects, and the first guess was the sibling's Gradle group. With the very common allprojects { group = "com.example" }, that prefix also matched the module's own com.example.* types, marking them unstable. Detection now relies solely on the IR declaration origin (IR_EXTERNAL_DECLARATION_STUB), which is the signal the Compose compiler itself uses and already covered every cross-module case. If you were affected, run ./gradlew stabilityDump to refresh your baseline — with the default failOnStabilityChange = true, stabilityCheck will otherwise fail on the resulting UNSTABLE → STABLE transitions.
• Cross-module types report an accurate reason: they were labelled UNSTABLE (has mutable properties or unstable members) even when they had none. They now read UNSTABLE (cross-module type without @Stable/@Immutable). Reasons are not compared by stabilityCheck, so this alone cannot fail a build.
• Stability verdicts no longer depend on compiler-plugin ordering: @StabilityInferred is honoured only on declarations from outside the module being compiled, where it is baked into the binary and is the intended cross-module channel. On a class in the module being compiled it exists only after the Compose compiler plugin's IR lowering has run, and whether that happens before or after this plugin is decided by the resolved order of kotlinCompilerPluginClasspath. The same source could therefore report STABLE in one build and RUNTIME in another. Our own property analysis is authoritative for source classes, and ignoring the annotation there also matches the IDE plugin, which only ever sees source.

Note for contributors

The sample :app module now resolves the runtime from its published coordinate like any consumer, instead of from the in-build :stability-runtime project. Two consequences: ./gradlew :stability-runtime:publishToMavenLocal must run before :app picks up local runtime edits, and after a version bump :app cannot build until the new version is published to Maven Local.

That change also shifted where the analyzer's IR pass sits relative to the Compose compiler plugin's IR lowering — plugin order follows the resolved kotlinCompilerPluginClasspath order, and the in-build project dependency used to push the analyzer behind Compose. Consumers were always on the other side of that boundary, so nothing changes for them, but app/stability/*.stability was regenerated and now records what a real consumer sees: composable-lambda parameters render in their pre-lowering form (@[Composable] ComposableFunction0<T> rather than Function2<Composer, Int, T>), and Icon.normalSealedClass reports RUNTIME instead of STABLE because @StabilityInferred is not yet attached to same-module classes when the pass runs. The analysis no longer depends on that ordering — see the @StabilityInferred entry under Fixed — so the regenerated baseline is now stable regardless of how the plugin classpath resolves.

• aadca58 Prepare for release 0.13.0 (#203)
• aa8fc62 Update Kotlin to 2.4.10 (#202)
• 6a94ff3 Support Gradle Isolated Projects (#107) (#201)
• 055e82e Document Kotlin Multiplatform support (#199)
• See full diff in compare view

Sourced from com.github.skydoves.compose.stability.analyzer's releases.

0.13.0

Upgrading

If you have committed .stability baselines in a multi-module project, run ./gradlew stabilityDump once after upgrading and commit the result.

This release fixes a false positive where a module's own types were reported UNSTABLE whenever a sibling Gradle module's group happened to be a package prefix (common with allprojects { group = "com.example" }). The corrected verdicts move UNSTABLE -> STABLE, and with the default failOnStabilityChange = true / ignoreNonRegressiveChanges = false, stabilityCheck reports improvements too, so it will fail until the baseline is refreshed.

Single-module projects are unaffected.

---

Changed

• Bumped Kotlin to 2.4.10 (from 2.4.0). Use the same Kotlin version as this library. The compiler plugin, runtime, Gradle plugin, Lint rules and IntelliJ plugin all build against 2.4.10, and every published target still compiles. No stability verdicts change: the Compose compiler's analysis/Stability.kt is byte-identical between 2.4.0 and 2.4.10, and re-running stabilityDump on the sample app produced no diff, so committed .stability baselines do not need refreshing for this bump alone.

  2.4.10's one Compose compiler fix, b/522127447 ("classes previously inferred stable now reported runtime/Uncertain"), is in ComposableFunctionBodyTransformer, not in stability inference. It restores the cast target type's stability when an argument is passed through a CAST/IMPLICIT_CAST, which affects the $changed metadata Compose computes per call-site argument. This analyzer reports the stability of a parameter's declared type, so the fix is orthogonal to what stabilityDump and the IDE surface.

• allowIncrementalDisabling is now scoped per project. Previously a stability task anywhere in the build disabled Kotlin incremental compilation in every project applying the plugin. Each project now decides based on its own task paths. ./gradlew stabilityDump, stabilityCheck and check behave identically; only a path-qualified invocation such as ./gradlew :app:stabilityCheck differs, and there it is more correct — that task only reads :app's own stability-info.json.

• The implicit :stability-runtime / :stability-lint project wiring is gone. The plugin used to call rootProject.findProject(...) and, when a module with either path existed, add that Project object as a dependency notation. That only ever resolved inside this repository, silently hijacked any consumer build containing a module with those names, and is deprecated in Gradle 9 (an error in Gradle 10). The published Maven coordinates are now always used; lint checks continue to ship inside the runtime AAR's lint.jar.

• The compiler plugin's projectDependencies option is deprecated and ignored. It stays registered so builds that pin the compiler artifact independently keep working, and will be removed in 1.0.

Fixed

• Gradle Isolated Projects compatibility (#107): the plugin no longer performs any cross-project access at configuration time, so builds using --isolated-projects / org.gradle.isolated-projects=true (incubating since Gradle 9.7) configure and compile cleanly. Two violations are gone:
  • collectProjectDependencies() walked rootProject.allprojects and read every sibling project's group, projectDir and path — including a filesystem scan of each sibling's sources — on every Kotlin compile-task configuration.
  • The incremental-compilation guard read gradle.taskGraph.allTasks, which observes tasks created by other projects.
• Types declared in the module being compiled are no longer mis-reported as UNSTABLE: cross-module detection used to match a parameter type's fully-qualified name against package prefixes guessed from sibling projects, and the first guess was the sibling's Gradle group. With the very common allprojects { group = "com.example" }, that prefix also matched the module's own com.example.* types, marking them unstable. Detection now relies solely on the IR declaration origin (IR_EXTERNAL_DECLARATION_STUB), which is the signal the Compose compiler itself uses and already covered every cross-module case. If you were affected, run ./gradlew stabilityDump to refresh your baseline — with the default failOnStabilityChange = true, stabilityCheck will otherwise fail on the resulting UNSTABLE → STABLE transitions.
• Cross-module types report an accurate reason: they were labelled UNSTABLE (has mutable properties or unstable members) even when they had none. They now read UNSTABLE (cross-module type without @Stable/@Immutable). Reasons are not compared by stabilityCheck, so this alone cannot fail a build.
• Stability verdicts no longer depend on compiler-plugin ordering: @StabilityInferred is honoured only on declarations from outside the module being compiled, where it is baked into the binary and is the intended cross-module channel. On a class in the module being compiled it exists only after the Compose compiler plugin's IR lowering has run, and whether that happens before or after this plugin is decided by the resolved order of kotlinCompilerPluginClasspath. The same source could therefore report STABLE in one build and RUNTIME in another. Our own property analysis is authoritative for source classes, and ignoring the annotation there also matches the IDE plugin, which only ever sees source.

Note for contributors

The sample :app module now resolves the runtime from its published coordinate like any consumer, instead of from the in-build :stability-runtime project. Two consequences: ./gradlew :stability-runtime:publishToMavenLocal must run before :app picks up local runtime edits, and after a version bump :app cannot build until the new version is published to Maven Local.

That change also shifted where the analyzer's IR pass sits relative to the Compose compiler plugin's IR lowering — plugin order follows the resolved kotlinCompilerPluginClasspath order, and the in-build project dependency used to push the analyzer behind Compose. Consumers were always on the other side of that boundary, so nothing changes for them, but app/stability/*.stability was regenerated and now records what a real consumer sees: composable-lambda parameters render in their pre-lowering form (@[Composable] ComposableFunction0<T> rather than Function2<Composer, Int, T>), and Icon.normalSealedClass reports RUNTIME instead of STABLE because @StabilityInferred is not yet attached to same-module classes when the pass runs. The analysis no longer depends on that ordering — see the @StabilityInferred entry under Fixed — so the regenerated baseline is now stable regardless of how the plugin classpath resolves.

Sourced from com.github.skydoves.compose.stability.analyzer's changelog.

[0.13.0] - 2026-08-22

Changed

• Bumped Kotlin to 2.4.10 (from 2.4.0). Use the same Kotlin version as this library. The compiler plugin, runtime, Gradle plugin, Lint rules and IntelliJ plugin all build against 2.4.10, and every published target still compiles. No stability verdicts change: the Compose compiler's analysis/Stability.kt is byte-identical between 2.4.0 and 2.4.10, and re-running stabilityDump on the sample app produced no diff, so committed .stability baselines do not need refreshing for this bump alone.

  2.4.10's one Compose compiler fix, b/522127447 ("classes previously inferred stable now reported runtime/Uncertain"), is in ComposableFunctionBodyTransformer, not in stability inference. It restores the cast target type's stability when an argument is passed through a CAST/IMPLICIT_CAST, which affects the $changed metadata Compose computes per call-site argument. This analyzer reports the stability of a parameter's declared type, so the fix is orthogonal to what stabilityDump and the IDE surface.

• allowIncrementalDisabling is now scoped per project. Previously a stability task anywhere in the build disabled Kotlin incremental compilation in every project applying the plugin. Each project now decides based on its own task paths. ./gradlew stabilityDump, stabilityCheck and check behave identically; only a path-qualified invocation such as ./gradlew :app:stabilityCheck differs, and there it is more correct — that task only reads :app's own stability-info.json.

• The implicit :stability-runtime / :stability-lint project wiring is gone. The plugin used to call rootProject.findProject(...) and, when a module with either path existed, add that Project object as a dependency notation. That only ever resolved inside this repository, silently hijacked any consumer build containing a module with those names, and is deprecated in Gradle 9 (an error in Gradle 10). The published Maven coordinates are now always used; lint checks continue to ship inside the runtime AAR's lint.jar.

• The compiler plugin's projectDependencies option is deprecated and ignored. It stays registered so builds that pin the compiler artifact independently keep working, and will be removed in 1.0.

Fixed

• Gradle Isolated Projects compatibility (#107): the plugin no longer performs any cross-project access at configuration time, so builds using --isolated-projects / org.gradle.isolated-projects=true (incubating since Gradle 9.7) configure and compile cleanly. Two violations are gone:
  • collectProjectDependencies() walked rootProject.allprojects and read every sibling project's group, projectDir and path — including a filesystem scan of each sibling's sources — on every Kotlin compile-task configuration.
  • The incremental-compilation guard read gradle.taskGraph.allTasks, which observes tasks created by other projects.
• Types declared in the module being compiled are no longer mis-reported as UNSTABLE: cross-module detection used to match a parameter type's fully-qualified name against package prefixes guessed from sibling projects, and the first guess was the sibling's Gradle group. With the very common allprojects { group = "com.example" }, that prefix also matched the module's own com.example.* types, marking them unstable. Detection now relies solely on the IR declaration origin (IR_EXTERNAL_DECLARATION_STUB), which is the signal the Compose compiler itself uses and already covered every cross-module case. If you were affected, run ./gradlew stabilityDump to refresh your baseline — with the default failOnStabilityChange = true, stabilityCheck will otherwise fail on the resulting UNSTABLE → STABLE transitions.
• Cross-module types report an accurate reason: they were labelled UNSTABLE (has mutable properties or unstable members) even when they had none. They now read UNSTABLE (cross-module type without @Stable/@Immutable). Reasons are not compared by stabilityCheck, so this alone cannot fail a build.
• Stability verdicts no longer depend on compiler-plugin ordering: @StabilityInferred is honoured only on declarations from outside the module being compiled, where it is baked into the binary and is the intended cross-module channel. On a class in the module being compiled it exists only after the Compose compiler plugin's IR lowering has run, and whether that happens before or after this plugin is decided by the resolved order of kotlinCompilerPluginClasspath. The same source could therefore report STABLE in one build and RUNTIME in another. Our own property analysis is authoritative for source classes, and ignoring the annotation there also matches the IDE plugin, which only ever sees source.

Note for contributors

The sample :app module now resolves the runtime from its published coordinate like any consumer, instead of from the in-build :stability-runtime project. Two consequences: ./gradlew :stability-runtime:publishToMavenLocal must run before :app picks up local runtime edits, and after a version bump :app cannot build until the new version is published to Maven Local.

That change also shifted where the analyzer's IR pass sits relative to the Compose compiler plugin's IR lowering — plugin order follows the resolved kotlinCompilerPluginClasspath order, and the in-build project dependency used to push the analyzer behind Compose. Consumers were always on the other side of that boundary, so nothing changes for them, but app/stability/*.stability was regenerated and now records what a real consumer sees: composable-lambda parameters render in their pre-lowering form (@[Composable] ComposableFunction0<T> rather than Function2<Composer, Int, T>), and Icon.normalSealedClass reports RUNTIME instead of STABLE because @StabilityInferred is not yet attached to same-module classes when the pass runs. The analysis no longer depends on that ordering — see the @StabilityInferred entry under Fixed — so the regenerated baseline is now stable regardless of how the plugin classpath resolves.

• aadca58 Prepare for release 0.13.0 (#203)
• aa8fc62 Update Kotlin to 2.4.10 (#202)
• 6a94ff3 Support Gradle Isolated Projects (#107) (#201)
• 055e82e Document Kotlin Multiplatform support (#199)
• See full diff in compare view

Sourced from com.github.skydoves.compose.stability.analyzer's releases.

0.13.0

Upgrading

If you have committed .stability baselines in a multi-module project, run ./gradlew stabilityDump once after upgrading and commit the result.

This release fixes a false positive where a module's own types were reported UNSTABLE whenever a sibling Gradle module's group happened to be a package prefix (common with allprojects { group = "com.example" }). The corrected verdicts move UNSTABLE -> STABLE, and with the default failOnStabilityChange = true / ignoreNonRegressiveChanges = false, stabilityCheck reports improvements too, so it will fail until the baseline is refreshed.

Single-module projects are unaffected.

---

Changed

• Bumped Kotlin to 2.4.10 (from 2.4.0). Use the same Kotlin version as this library. The compiler plugin, runtime, Gradle plugin, Lint rules and IntelliJ plugin all build against 2.4.10, and every published target still compiles. No stability verdicts change: the Compose compiler's analysis/Stability.kt is byte-identical between 2.4.0 and 2.4.10, and re-running stabilityDump on the sample app produced no diff, so committed .stability baselines do not need refreshing for this bump alone.

  2.4.10's one Compose compiler fix, b/522127447 ("classes previously inferred stable now reported runtime/Uncertain"), is in ComposableFunctionBodyTransformer, not in stability inference. It restores the cast target type's stability when an argument is passed through a CAST/IMPLICIT_CAST, which affects the $changed metadata Compose computes per call-site argument. This analyzer reports the stability of a parameter's declared type, so the fix is orthogonal to what stabilityDump and the IDE surface.

• allowIncrementalDisabling is now scoped per project. Previously a stability task anywhere in the build disabled Kotlin incremental compilation in every project applying the plugin. Each project now decides based on its own task paths. ./gradlew stabilityDump, stabilityCheck and check behave identically; only a path-qualified invocation such as ./gradlew :app:stabilityCheck differs, and there it is more correct — that task only reads :app's own stability-info.json.

• The implicit :stability-runtime / :stability-lint project wiring is gone. The plugin used to call rootProject.findProject(...) and, when a module with either path existed, add that Project object as a dependency notation. That only ever resolved inside this repository, silently hijacked any consumer build containing a module with those names, and is deprecated in Gradle 9 (an error in Gradle 10). The published Maven coordinates are now always used; lint checks continue to ship inside the runtime AAR's lint.jar.

• The compiler plugin's projectDependencies option is deprecated and ignored. It stays registered so builds that pin the compiler artifact independently keep working, and will be removed in 1.0.

Fixed

• Gradle Isolated Projects compatibility (#107): the plugin no longer performs any cross-project access at configuration time, so builds using --isolated-projects / org.gradle.isolated-projects=true (incubating since Gradle 9.7) configure and compile cleanly. Two violations are gone:
  • collectProjectDependencies() walked rootProject.allprojects and read every sibling project's group, projectDir and path — including a filesystem scan of each sibling's sources — on every Kotlin compile-task configuration.
  • The incremental-compilation guard read gradle.taskGraph.allTasks, which observes tasks created by other projects.
• Types declared in the module being compiled are no longer mis-reported as UNSTABLE: cross-module detection used to match a parameter type's fully-qualified name against package prefixes guessed from sibling projects, and the first guess was the sibling's Gradle group. With the very common allprojects { group = "com.example" }, that prefix also matched the module's own com.example.* types, marking them unstable. Detection now relies solely on the IR declaration origin (IR_EXTERNAL_DECLARATION_STUB), which is the signal the Compose compiler itself uses and already covered every cross-module case. If you were affected, run ./gradlew stabilityDump to refresh your baseline — with the default failOnStabilityChange = true, stabilityCheck will otherwise fail on the resulting UNSTABLE → STABLE transitions.
• Cross-module types report an accurate reason: they were labelled UNSTABLE (has mutable properties or unstable members) even when they had none. They now read UNSTABLE (cross-module type without @Stable/@Immutable). Reasons are not compared by stabilityCheck, so this alone cannot fail a build.
• Stability verdicts no longer depend on compiler-plugin ordering: @StabilityInferred is honoured only on declarations from outside the module being compiled, where it is baked into the binary and is the intended cross-module channel. On a class in the module being compiled it exists only after the Compose compiler plugin's IR lowering has run, and whether that happens before or after this plugin is decided by the resolved order of kotlinCompilerPluginClasspath. The same source could therefore report STABLE in one build and RUNTIME in another. Our own property analysis is authoritative for source classes, and ignoring the annotation there also matches the IDE plugin, which only ever sees source.

Note for contributors

The sample :app module now resolves the runtime from its published coordinate like any consumer, instead of from the in-build :stability-runtime project. Two consequences: ./gradlew :stability-runtime:publishToMavenLocal must run before :app picks up local runtime edits, and after a version bump :app cannot build until the new version is published to Maven Local.

That change also shifted where the analyzer's IR pass sits relative to the Compose compiler plugin's IR lowering — plugin order follows the resolved kotlinCompilerPluginClasspath order, and the in-build project dependency used to push the analyzer behind Compose. Consumers were always on the other side of that boundary, so nothing changes for them, but app/stability/*.stability was regenerated and now records what a real consumer sees: composable-lambda parameters render in their pre-lowering form (@[Composable] ComposableFunction0<T> rather than Function2<Composer, Int, T>), and Icon.normalSealedClass reports RUNTIME instead of STABLE because @StabilityInferred is not yet attached to same-module classes when the pass runs. The analysis no longer depends on that ordering — see the @StabilityInferred entry under Fixed — so the regenerated baseline is now stable regardless of how the plugin classpath resolves.

Sourced from com.github.skydoves.compose.stability.analyzer's changelog.

[0.13.0] - 2026-08-22

Changed

• Bumped Kotlin to 2.4.10 (from 2.4.0). Use the same Kotlin version as this library. The compiler plugin, runtime, Gradle plugin, Lint rules and IntelliJ plugin all build against 2.4.10, and every published target still compiles. No stability verdicts change: the Compose compiler's analysis/Stability.kt is byte-identical between 2.4.0 and 2.4.10, and re-running stabilityDump on the sample app produced no diff, so committed .stability baselines do not need refreshing for this bump alone.

  2.4.10's one Compose compiler fix, b/522127447 ("classes previously inferred stable now reported runtime/Uncertain"), is in ComposableFunctionBodyTransformer, not in stability inference. It restores the cast target type's stability when an argument is passed through a CAST/IMPLICIT_CAST, which affects the $changed metadata Compose computes per call-site argument. This analyzer reports the stability of a parameter's declared type, so the fix is orthogonal to what stabilityDump and the IDE surface.

• allowIncrementalDisabling is now scoped per project. Previously a stability task anywhere in the build disabled Kotlin incremental compilation in every project applying the plugin. Each project now decides based on its own task paths. ./gradlew stabilityDump, stabilityCheck and check behave identically; only a path-qualified invocation such as ./gradlew :app:stabilityCheck differs, and there it is more correct — that task only reads :app's own stability-info.json.

• The implicit :stability-runtime / :stability-lint project wiring is gone. The plugin used to call rootProject.findProject(...) and, when a module with either path existed, add that Project object as a dependency notation. That only ever resolved inside this repository, silently hijacked any consumer build containing a module with those names, and is deprecated in Gradle 9 (an error in Gradle 10). The published Maven coordinates are now always used; lint checks continue to ship inside the runtime AAR's lint.jar.

• The compiler plugin's projectDependencies option is deprecated and ignored. It stays registered so builds that pin the compiler artifact independently keep working, and will be removed in 1.0.

Fixed

• Gradle Isolated Projects compatibility (#107): the plugin no longer performs any cross-project access at configuration time, so builds using --isolated-projects / org.gradle.isolated-projects=true (incubating since Gradle 9.7) configure and compile cleanly. Two violations are gone:
  • collectProjectDependencies() walked rootProject.allprojects and read every sibling project's group, projectDir and path — including a filesystem scan of each sibling's sources — on every Kotlin compile-task configuration.
  • The incremental-compilation guard read gradle.taskGraph.allTasks, which observes tasks created by other projects.
• Types declared in the module being compiled are no longer mis-reported as UNSTABLE: cross-module detection used to match a parameter type's fully-qualified name against package prefixes guessed from sibling projects, and the first guess was the sibling's Gradle group. With the very common allprojects { group = "com.example" }, that prefix also matched the module's own com.example.* types, marking them unstable. Detection now relies solely on the IR declaration origin (IR_EXTERNAL_DECLARATION_STUB), which is the signal the Compose compiler itself uses and already covered every cross-module case. If you were affected, run ./gradlew stabilityDump to refresh your baseline — with the default failOnStabilityChange = true, stabilityCheck will otherwise fail on the resulting UNSTABLE → STABLE transitions.
• Cross-module types report an accurate reason: they were labelled UNSTABLE (has mutable properties or unstable members) even when they had none. They now read UNSTABLE (cross-module type without @Stable/@Immutable). Reasons are not compared by stabilityCheck, so this alone cannot fail a build.
• Stability verdicts no longer depend on compiler-plugin ordering: @StabilityInferred is honoured only on declarations from outside the module being compiled, where it is baked into the binary and is the intended cross-module channel. On a class in the module being compiled it exists only after the Compose compiler plugin's IR lowering has run, and whether that happens before or after this plugin is decided by the resolved order of kotlinCompilerPluginClasspath. The same source could therefore report STABLE in one build and RUNTIME in another. Our own property analysis is authoritative for source classes, and ignoring the annotation there also matches the IDE plugin, which only ever sees source.

Note for contributors

The sample :app module now resolves the runtime from its published coordinate like any consumer, instead of from the in-build :stability-runtime project. Two consequences: ./gradlew :stability-runtime:publishToMavenLocal must run before :app picks up local runtime edits, and after a version bump :app cannot build until the new version is published to Maven Local.

That change also shifted where the analyzer's IR pass sits relative to the Compose compiler plugin's IR lowering — plugin order follows the resolved kotlinCompilerPluginClasspath order, and the in-build project dependency used to push the analyzer behind Compose. Consumers were always on the other side of that boundary, so nothing changes for them, but app/stability/*.stability was regenerated and now records what a real consumer sees: composable-lambd...

Description has been truncated